fix(rubocop) support projects that do not use bundler #2706
Conversation
|
Testing done:
In each case, :LspLog shows no problems |
| -- prepend 'bundle exec' to cmd if bundler is being used | ||
| local gemfile_path = util.path.join(root_dir, 'Gemfile') | ||
| if util.path.exists(gemfile_path) then | ||
| config.cmd = { 'bundle', 'exec', unpack(config.cmd) } |
There was a problem hiding this comment.
@gongfarmer @glepnir FYI, I believe this change has broken my use-case, which was working previously. I am now unable to override cmd.
I am in a rails app, so bundle is available. But the version of rubocop installed in my rails app does not have the lsp. I would like to use the globally installed version, which I was previously doing by overriding cmd:
cmd = { "rubocop", "--lsp", },
But now this seems to not be possible. I have also tried overriding on_new_config, but my overridden function doesn't seem to replace the default one.
lspconfig.rubocop.setup({
cmd = { "rubocop", "--lsp", },
on_attach = on_attach,
capabilities = capabilities,
on_new_config = function (new_config, new_root_dir)
-- noop
end,
})
This shows up in the lsp log, suggesting the default on_new_config is still active.
[ERROR][2023-07-08 15:38:29] .../vim/lsp/rpc.lua:734 "rpc" "bundle" "stderr" "invalid option: --lsp\nFor usage information, use --help\n"
There was a problem hiding this comment.
Update: I think I've figured this out. Providing my own on_new_config implementation doesn't override the default. Instead, both are executed. So I need to actually overwrite the effects of the default on_new_config.
My working configuration:
lspconfig.rubocop.setup({
on_attach = on_attach,
capabilities = capabilities,
on_new_config = function (new_config, new_root_dir)
new_config.cmd = { "rubocop", "--lsp", }
end,
})
|
I am not sure about these command. @gongfarmer could you take a look at this ? |
|
We should delete the Rails devs who actually want to manage their rubocop version through bundler can then configure this specially. This would match the behaviour of the nvim-lspconfig configurations for ruby_ls and solargraph . I am travelling today but will put up a PR for that tomorrow. @tradiff I do not understand why your configuration was running twice, using the old config and then the new one. This seems like an nvim-lspconfig bug to me, or at least a surprising behaviour that I was unaware of. I am not knowledgeable about nvim-lspconfig. @glepnir Is it expected that the language server would be started twice when there is an |
|
I don't think it's starting two different instances of the language server. I think both This might not be a "bug", but maybe room for improvement from nvim-lspconfig on the principal of least surprise.
Looking at other server defaults, using an |
|
I will confess that I don't understand everything as I am no expert in neovim, LSP or ruby. But I receive this error when I run rubocop in my rails project(s): Testing on my console, I see this seems to be the same issue @tradiff was experiencing. I'll try his workaround. |
The existing rubocop lsp configuration uses the 'bundle exec' command as a prefix to run rubocop.
This is the correct way to do it for projects using the bundler gem (including all rails projects.)
However that configuration is broken for ruby projects not using bundler. The LSP fails to start and an error message is shown on startup.
This PR makes the default configuration work for either case, by detecting whether bundler is in use and using the correct command.